Current cellular systems provide browsing the internet and access to services on the internet. The packet data that the cellular system transmits to the end user in these situations must be handled differently than for circuit-switched speech in that the cellular system should maintain a steady flow of packets between the internet source and the end user so that services are not interrupted. Packet data flow control (referred to simply as flow control) in Wideband Code Division Multiple Access (WCDMA) helps achieve this goal. Flow control in WCDMA is distributed between two nodes: the radio network controller (RNC) and the radio base station (RBS). The RBS is responsible for maintaining a steady flow of packets to the User Equipment (UE) over the air interface to provide a satisfactory user experience, e.g., during web browsing. FIG. 1 is a diagram used to explain WCDMA flow control.
The RNC is responsible for ensuring that data is available in the RBS for transmission, and to facilitate this, the RNC sends Radio Link Control (RLC) data via a Transport Network (TN) to the RBS. The RNC thereby affects the buffer level in the RBS by sending RLC PDU's to the RBS via a TN Frame Protocol (FP). The RBS sends capacity allocations (CA) as input to the RNC, and the RNC typically responds by sending an appropriate amount of data with the specified rate to the RBS over the Iub interface.
Because the RLC protocol is terminated in the RNC and in the UE, any RLC data residing in an RBS queue is seen as delayed by the RLC entities involved in the data transmission between the RNC and the UE. As a result, the RNC will, at poll timer expiry, poll data that has already been transmitted from the RNC to the RBS, but which is still residing in the RBS queue for the UE, and consequently, not yet acknowledged by the UE. Thus, if the amount of data in the RBS Priority Queue (PQ) (a term used in WCDMA) is large and the data rate over the air interface (Uu) is low, then the RLC entity in the RNC will poll the RLC entity in the UE as to whether it has received a particular data packet, even though no data has been lost. Consequently, this will lead to unnecessary retransmissions of RLC packet data units (PDU's) with a poll bit set or poll superfields (POLL_SUFI's).
Another problem is posed by RLC retransmissions. RLC retransmissions delayed by data already buffered in the PQ can lead to multiple requests for the same data even though the previously retransmitted data is already in transit, but still buffered in the RBS PQ. In the delayed retransmissions situation, the UE may, due to timer status prohibit expiry or other status reporting trigger, send additional RLC status reports before the initial retransmission even has been transmitted to the UE over the air interface leading to a situation where multiple copies of the same data will be sent both over the TN and the Uu interface. This results in an inefficient use of the TN and air interface resources since the additional copies of retransmitted RLC PDU's do not contribute to the user experienced throughput since they will be discarded as duplicates by the receiving RLC entity in the UE.
In traditional WCDMA downlink flow control, i.e., for High Speed Downlink Packet Access (HSDPA), the RNC arranges received downlink packets in a queue herein referred to as the RNC queue and transmits packages to the RBS according to the maximum bitrates for transmission over the Iub interface.
A more recent flow control approach, such as Active Queue Management (AQM) flow control or Distributed Active Queue Management (D-AQM), avoids buildup in the RNC queue at the RNC by allowing the RNC to forward data to the RBS as soon as possible. This results in queuing in the RBS and not in the RNC, in contrast to traditional WCDMA flow control which attempts to limit the queue length in the RBS to avoid spurious RLC retransmissions. As a result, the RLC Round Trip Time (RTT) can be expected to vary over a greater range for a TN relying on D-AQM flow control as opposed to a TN that uses traditional flow control. One way to handle this would be to increase the RLC timers that are used to monitor the maximum allowed queue delays, but this would result in poor performance due to lower peak throughput and excessive polling delays in certain scenarios, such as short data transmissions when only the last RLC PDU (which carries the poll) is lost.
While D-AQM attempts to adjust the PQ buffer length in the RBS to the Uu rate, typically targeting a certain buffer length or dwell time, the Uu bit rate for services over the radio interface varies significantly over short periods of time, sometimes resulting in large PQ's and low Uu bit rates. In these instances, it takes time for the RBS to shorten the PQ and adjust to the lower Uu bit rate, leading to an increased RLC RTT and subsequent delay of RLC polls and retransmissions. Consequently, D-AQM may have difficulty in maintaining a desired queue (PQ) length which may lead to wasted bandwidth both in the TN and radio network (RAN) due to the unnecessary transmission of polls and multiple copies of RLC retransmissions.
One objective of flow control is to effectively utilize the air interface between the RBS and the UE since radio spectrum is a scarce resource. If the flow of data packets is interrupted or slowed down unnecessarily, then the user or cell throughput suffers. For this reason, it is important to keep the priority queues (PQs) of the RBS non-empty with a suitable margin (a typical but example margin is 125 ms) to avoid poor user throughput.
Another important flow control objective is to avoid the amount of data buffered in the PQ becoming too large and the packet dwell time in the PQ becoming too long. Stated differently, flow control should aim to keep the PQ in the RBS as short as possible while ensuring that enough data is available to fully utilize the air interface capacity. In addition to the problems already noted above, a large RBS PQ leads to large losses of data at High Speed-Downlink Shared Channel (HS-DSCH) cell changes, which also leads to a large number of RLC retransmissions.
Yet another problem is that aggressive TCP applications do not always respond to traditional flow control schemes such as Active Queue Management (AQM) congestion control based on premeditated packet drops. An example of an aggressive TCP application is one which starts a large number of TCP flows in parallel, each carrying only a small amount of data. In such scenarios, traditional AQM schemes may fail to maintain the RBS buffer within targeted values, leading to an excessive PQ buffer build-up. The effect is long download times as illustrated in FIG. 2, which is a graph showing an example of RBS buffer dwell time when AQM flow control is used in a WCDMA system. When multiple data flows are suddenly started, an AQM buffer dwell time “run away” situation occurs, as pointed out in the Figure.